The present invention relates generally to smart cards. More specifically, the present invention relates to a technique for delegating the management of applications on a smart card such as loading, installation and deletion.
Smart card technologies hold great promise as the replacement for magnetic stripe card technology. The adoption of smart cards, however, on a massive scale has been slow to develop. One reason for this slow adoption is the lack of standards among the many different vendor implementations of smart cards and the difficulties with implementing a new technology.
Recently, significant standards in the smart card area have been created. The standards, however, have been primarily targeted at either low levels of interoperability, such as the mechanical and electrical standards specified in the EMV specifications, or at the application layer in terms of developing standard chip credit, debit and purse applications. The main benefit of the standards has been realized in single-application smart cards, but has not significantly improved the situation for multi-applications smart cards.
The mid-1990s saw the introduction of various open systems standards for application development. For example, three technologies in this area are JAVA Card from Sun Microsystems, Inc., Smart Card for Windows from Microsoft Corporation, and MULTOS from MAOSCO, Ltd. These technology standards provide an important part of the solution toward common programming standards allowing application portability between different manufacturers card implementations. Other recent efforts have also addressed particular issues with multi-application smart cards. For example, U.S. patent application Ser. No. 09/046,994 filed Mar. 24, 1998, and U.S. patent application Ser. No. 09/046,993 filed Mar. 4, 1998 address issues related to post-issuance downloading and life cycle, each of which are hereby incorporated by reference.
In prior art smart cards only the issuer of the card has been allowed to perform certain management functions of applications such as loading an application onto the card, installing the application and deleting the application from the card. This reliance upon the issuer exclusively for loading, installing and deleting applications can lead to some difficulties. For example, should a store develop a loyalty application for its customers that it wishes to load and install onto their customer""s smart cards, the store would be precluded from doing so if only the card issuer is allowed to perform such functions. Arranging for the store to contact the issuer, and arranging for the issuer to load the store""s application onto its customer""s smart cards presents basic logistical problems such as application security and access to cards. For example, it would be best if the store could download an application onto a customer card while the customer visited the store. If only the issuer can download the application, it becomes more difficult to access the customer card.
In addition to logistical problems, there are privacy issues with regard to an application developer""s private customer data. For example, if a loyalty application of a particular third party is loaded onto a smart card by the issuer, it may be still necessary to add private customer-specific data onto each individual card for use by loyalty application. This private customer information may very well be the private property of the third party, and the third party may be unwilling to transfer this private information to a card issuer to allow the card issuer to load and install the third party""s loyalty data. For instance, Hertz would likely be unwilling to provide private customer information regarding it top renters to the bank that is loading Hertz""s application onto a smart card.
Other mechanical difficulties are presented should a customer desire to download and install a third party""s application at the third party""s site if only the issuer is allowed to download and install an application. For example, should a customer wish to download a loyalty application while at the third party""s place of business during a smart card transaction, it would be first be necessary for the card acceptance device to connect to the issuer host to download the loyalty application, and then connect to the third party""s host computer in order to receive custom information for the initialization and personalization of that application. Such multiple connections at load time make the transaction more complex, time consuming and are more prone to failure. In addition, as a practical matter, should a customer wish to download and install an application onto his smart card, it is more than likely that the customer is physically present at a third party site rather than at the issuer""s site.
Further difficulties may be encountered if only the issuer is allowed to delete an application that belongs to the application provider/developer from a customer smart card. For example, the application is the responsibility of the application provider and is his liability. Should an agreement expire between the provider and the issuer, it may be more desirable for the provider to be able to delete his property (the application) from the smart card, rather than relying upon the issuer to do so for him. A further difficulty encountered if only the issuer is allowed to delete an application relates to the application data. When an application is deleted, the application data is deleted as well. Therefore, it would be desirable to allow the application provider to extract any relevant data (e.g., loyalty points from a loyalty application) from the card before the application is deleted. Since the card issuer does not have the provider""s application keys, it would be near impossible for the card issuer to extract any information that required any kind of authentication. (The provider may also not desire that the issuer have access to the extracted information.)
Therefore, it would be desirable to allow another entity besides the card issuer to manage various functions associated with card applications such as loading, installing and deleting. It would further be desirable to allow the issuer to still be able to manage and control which applications are present on the smart card.
To achieve the foregoing, and in accordance with the purpose of the present invention, a technique is disclosed that extends the functionality of a security domain and allows it to perform delegated management of smart card applications. For example, embodiments of the present invention allow a security domain to perform delegated loading, installation and/or deletion of an application. By delegating this management to their security domain, a provider of an application is assured of more direct control and management of their application, yet an issuer still maintains some control over the management of the card.
This concept of delegated management allows the card issuer the option of empowering application providers to initiate changes to the issuer""s smart cards that are pre-approved by the card issuer. This pre-approval ensures that only card content changes that the card issuer has approved will be accepted and processed by a card manager of a smart card. This delegation of control in the card update process allows application providers more flexibility in managing their own applications on the card issuer""s cards.
In one embodiment, a method of delegated loading of an application onto a smart card first receives a load command from an application provider via a card acceptance device. The load command includes an indication of an application to be loaded and an appended command authentication pattern. Next, the load command is verified using the command authentication pattern. Then, an application is received from an application provider via the card acceptance device; the application also includes an appended application authentication pattern which is used to verify the application. Finally, the application is loaded into memory of the smart card. Thus, an application provider is allowed to load an application onto a smart card.
In another embodiment, a system for delegated loading of an application onto a smart card includes a host computer under control of an application provider and a software application to be loaded onto a smart card. The application includes an appended application authentication pattern produced by an issuer of the smart card that verifies the application to the smart card. The system also includes a smart card acceptance device linked to the host computer and a smart card included in the card acceptance device. The smart card includes code arranged to verify the application using the application authentication pattern. Thus, the application provider is allowed to load the application onto the smart card.